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1.0  EXECUTIVE  SUMMARY 


This  technical  report  summarizes  the  work  accomplished  in  the  performance  of  the  GIESim  communications 
Modeling  and  Simulations  project.  This  work  was  performed  by  Syracuse  Research  Corporation  (SRC),  Science 
Applications  International  Corporation  (SAIC),  Prediction  Systems,  Inc.  (PSI)  and  Frontier  Technology,  Inc.  (FTI) 
for  the  Air  Force  Research  Faboratory  (AFRF),  Distributed  Information  Systems  Branch  (IFGA),  under  Contract 
F30602-03-C-0074,  in  accordance  to  Contract  Delivery  Requirement  Fist  (CDRF)  A003. 

The  objective  of  the  effort  was  the  integration  of  communications  and  network  modeling  and  simulation  (M&S) 
toolkits  into  the  Global  Information  Enterprise  (GIE)  Modeling  and  Simulation  (GIESim)  framework  for  effective 
and  efficient  user  analysis  of  candidate  communications  architectures  and  technologies. 

The  three-phased  effort  commenced  in  July  2002  and  concluded  in  February  2005.  Phase  I  had  three  major  Goals: 

•  Compile  and  Summarize  the  Capabilities  of  Candidate  Simulation  Tools 

•  Map  Simulation  Tools  into  the  GIESim  and  Joint  Battlespace  Infosphere  (JBI)  Simulation  (JBISim) 

•  Define  the  Roles  and  Interactions  of  the  Candidate  Simulation  Tools 

Phase  II  of  this  effort  was  the  integration  of  communications  and  network  modeling  and  simulation  (M&S)  toolkits 
into  the  Global  Information  Enterprise  (GIE)  Modeling  and  Simulation  (GIESim)  framework.  This  phase  was  a 
simulation  development  program  to  further  define,  design,  and  implement  a  Modeling  and  Simulation  (M&S) 
framework  for  GIE  and  was  developed  in  a  contractor  and  government  team  environment  that  brought  together 
M&S  and  subject  area  expertise. 

Phase  III  was  the  merging  of  the  GIESim  Joint  Tactical  Information  Distribution  System  (JTIDS)  simulation  with 
the  Joint  Semi-Automated  Forces  (JSAF)  project.  The  GIESim  JTIDS  added  tactical  communications  modeling  to 
JSAF.  Also  the  merger  of  the  JTIDS/Fink-16  capabilities  from  GIESim  with  JSAF  was  a  first  step  toward  applying 
the  GIESim  rapid  communications  modeling  approach  to  a  large  simulation  environment.  Of  equal  importance  in 
GIESim  Phase  III  was  the  Modeling  and  Simulation  (M&S)  demonstration  between  JSAF  and  GIESim  JTIDS  that 
tested  the  interoperation  and  that  had  a  direct  impact  on  an  observer. 

Sections  2,  3,  and  4  summarize  GIESim’ s  Phase  I,  II,  and  III  respectively,  including  their  goals,  participants, 
accomplishments,  and  recommendations  for  the  effort.  Section  5  provides  a  synopsis  of  the  GIESim-JSAF 
demonstration.  Section  6  provides  Lessons  Learned  while  Section  7  provides  ideas  for  proposed  future  work. 
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2.0  GIESIM  PHASE  I 


2.1  GIESim  Phase  I  Goals 

The  three  major  Goals  of  the  GIESim  Phase  I  commenced  in  July  2002  and  concluded  December  2002.  The 
following  tasks  were  included: 

•  Compiled  and  Summarized  the  Capabilities  of  Candidate  Simulation  Tools 

•  Mapped  Simulation  Tools  into  the  GIESim  and  JBISim  Architectures 

•  Define  the  Roles  and  Interactions  of  the  Candidate  Simulation  Tools 

Working  closely  with  AFRL  the  team  developed  an  overall  GIESim  architecture.  SRC’s  familiarity  and  direct 
experience  with  many  of  the  candidate  simulation  tools  offered  a  unique  opportunity  to  provide  broad  guidance  in 
developing  the  GIESim  framework. 

2.2  GIESim  Phase  I  Participants 

During  Phase  I  of  the  program,  the  Modeling  and  Simulation  team  of  Syracuse  Research  Corporation  (SRC), 
Science  Applications  International  Corporation  (SAIC),  Prediction  Systems,  Inc.  (PSI),  and  Frontier  Technology, 
Inc.  (FTI)  worked  closely  with  AFRL/IFGC  (Information  Connectivity  Branch)  on  the  effort. 

2.3  GIESim  Phase  I  Accomplishments 

2.3.1  Compile  and  Summarize  the  Capabilities  of  Candidate  Simulation  Tools 

To  understand  how  simulation  tools  may  be  used  to  simulate  the  GIE  and  JBI,  it  was  essential  that  a  single 
compilation  of  the  simulation  tool  capabilities  be  generated.  Many  of  the  candidate  tools  were  studied  under  the 
Satellite  Communications  System  Simulation  Phase  I  SBIR  program  for  operation  with  the  Communications 
Analysis  and  Simulation  Toolkit  (CAST).  The  tools  selected  were  as  follows: 

1.  OPNET  is  a  discrete  event  simulator  environment  used  to  simulate  and  analyze  hierarchical  network 
models  with  integrated  analysis  and  animation  tools.  Ficenses  are  sold  at  various  levels  of  user  complexity. 
There  are  multiple  “guru”  products  that  are  for  analyst  and  planner  level  users.  They  come  with  model 
libraries  and  allow  the  user  to  “drag  and  drop”  models  to  create  networks  to  analyze.  OPNET  modeler 
allows  the  user  to  modify  models  and  create  them  from  scratch  as  well  as  having  the  capabilities  of  the 
“guru”  level  products.  For  developers  who  want  access  to  the  software  design  tools  of  OPNET,  the  OPNET 
Development  Kit  (ODK)  is  available.  It  allows  access  to  OPNET ’s  software  development  tools  and  has  all 
the  functionality  of  a  modeler.  OPNET  has  a  large  user  base  with  a  strong  presence  in  the  military 
community.  They  have  a  comprehensive  library  of  detailed  equipment,  protocol,  and  application  models 
including  vendor-specific  equipment  models.  As  does  any  of  the  more  powerful  network  simulation  tools, 
OPNET  has  a  large  learning  curve  for  new  users.  To  use  OPNET  effectively,  users  are  required  to  invest 
time  in  training  and  practice.  With  the  wireless  add-on  module,  OPNET  has  the  capability  to  model 
wireless  and  satellite  links.  Much  of  the  work  done  in  wireless  using  OPNET  has  been  done  in  classified 
domains  making  it  difficult  to  find  many  readily  available  wireless  models. 

2.  NET  WARS  is  a  communications  modeling  tool  being  developed  by  OPNET  for  DISA.  Its  purpose  is  to 

enable  the  warfighter  to  credibly  model  tactical  and  operational  communications  demands  with  all  the 
stresses  that  combat  places  on  communications  systems.  The  main  objective  of  NETWARS  is  to  provide  an 
integrated  ability  to  analyze  communication  networks;  a  corollary  objective  is  to  provide  validated 
simulation  capability  with  asset  and  information  exchange  requirement  (IER)  model  databases.  NETWARS 
is  designed  to  quantify  the  risks  and  identify  C4  deficiencies  before  US  Forces  are  committed  into  any 
contingency.  To  achieve  this  end,  NETWARS  will  evaluate  the  risks  of  planned  communication  networks 
that  will  be  supporting  warfighter  operations  by  factoring  in  movement,  environmental  factors  and  terrain 
effects.  NETWARS  development  is  currently  focusing  on  model  interoperability  (i.e.,  standards),  customer 
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support  and  training,  improved  realism,  expanding  the  model  library,  improved  usability,  operational  test 
and  evaluation  (OT&E),  and  better  documentation. 

3.  Satellite  Tool  Kit  (STK)  is  a  suite  of  software  modules  produced  by  Analytical  Graphics,  Inc.  (AGI)  to 
analyze  satellite  assets  and  orbits,  integrated  land/sea/air/space  systems,  communications  links,  and  3-D 
models.  STK  has  developed  high  precision,  validated,  orbital  propagation  models.  It  is  extremely  powerful 
for  dynamic  analyses  that  involve  determining  access  between  two  or  more  objects.  With  the  visualization 
option  (VO),  STK  can  create  stunning  animated  3-D  visualizations.  The  STK  user  interface  is  intuitive  and 
fairly  easy  to  learn  to  use.  STK  is  limited  to  the  physical  layer  analyses.  It  has  very  limited  networking 
capabilities  and  has  no  user-defined  modeling  capabilities. 

4.  General  Simulation  System  (GSS)  is  a  visual  CAD  environment  produced  by  Prediction  Systems,  Inc. 
(PSI)  to  support  Model  Development,  Scenario  Development,  Simulation,  and  Analysis.  PSI  provides 
custom  simulations  tailored  to  customer  needs.  GSS  is  provided  to  all  customers  without  licensing  costs.  It 
is  able  to  provide  solutions  quickly  by  reusing  and  modifying  models  from  its  large  archive.  Customers 
receive  all  the  source  code  for  their  simulations  and  models  and  can  modify  it  as  they  wish.  The  source 
code  is  written  in  a  CAD-type  environment  which  helps  document  the  simulation  architecture.  GSS 
simulations  tend  to  run  quickly  and  allow  users  to  interact  graphically  with  the  simulation  as  it  is  running. 
For  example,  in  one  of  their  JTID  simulations,  the  user  starts  the  simulation  and  can  view  the  connectivity 
of  the  network.  While  the  simulation  is  running,  the  users  can  move  radios  around  and  add  new  radios  and 
immediately  see  how  the  connectivity  is  affected.  GSS  is  not  flashy  COTS  type  software  with  generalized 
drag  and  drop  libraries  for  doing  network  simulations.  GSS  requires  an  experienced  user  to  make  effective 
use  of  the  tool. 

5.  The  Network  Simulator  (Ns-2)  is  an  object-oriented  simulator  targeted  at  networking  research  that 
provides  substantial  support  for  simulation  of  TCP,  routing,  and  multicast  protocols  over  wired  and 
wireless  (local  and  satellite)  networks.  Ns-2  compiles  under  UNIX,  Linux,  and  Windows.  The  simulator  is 
open  source  and  can  be  rewritten  as  needed. 

There  is  a  large  supply  of  free  contributed  code  and  models  for  Ns-2.  The  contributed  code  covers  the  areas 
of  routing,  mobility,  wireless,  satellite,  topology  and  traffic  generators,  scheduling  and  queue  management, 
multicast,  transport,  and  support.  Animations  of  Ns-2  simulations  can  be  recorded  with  another  software 
tool  called  the  Network  Animator  (NAM). 

Ns-2  is  not  a  finished  and  polished  product.  Ns-2  has  validation  tests  that  cover  many  protocols.  However, 
users  are  responsible  for  verifying  that  Ns-2  is  accurate  for  their  purposes. 

6.  SPEEDES  simulation  engine  allows  the  simulation  builder  to  perform  optimistic  parallel  processing  on 
applications  that  are  typically  time-constrained  (too  many  events  to  process  in  a  limited  amount  of  time).  In 
optimistic  parallel  processing,  each  processor  simulates  its  objects  as  quickly  as  possible.  If  an  event  occurs 
that  affects  an  object  on  another  processor  (processor  B)  it  (processor  A)  notifies  that  processor  of  the 
event.  In  the  case  where  processor  B  has  already  moved  on  to  a  simulation  time  past  the  simulation  time  of 
the  incoming  event,  processor  B  will  rollback  only  those  objects  affected  by  the  event.  This  algorithm 
improves  the  speed  of  the  simulation  over  a  parallel  processing  algorithm  that  requires  that  all  processors 
stay  synched  up  in  simulation  time.  SPEEDES  has  been  designed  to  implement  High  Level  Architecture 
(HLA).  SPEEDES  does  not  include  a  model  library  of  communication/network  devices  or  protocols.  There 
are  no  “drag  and  drop”  interfaces  for  building  networks  to  be  simulated.  SPEEDES  requires  an 
experienced  user/programmer  in  order  to  effectively  use  this  tool. 

2.3.2  Map  Simulation  Tools  into  GIESim  and  JBISim  Architecture 

Figure  2-1  outlines  the  GIESim  conceptual  architecture.  The  complete  scenario  is  provided  as  three  separate  parts: 
mission  (Scenario),  equipment  (Device  and  Protocol  Database),  and  doctrine  (Thread/IER  Database).  These  three 
parts  are  compiled  and  linked  together  by  the  Intelligent  Scenario  Compiler  to  form  a  complete  simulation.  A  force- 
level  simulator  will  provide  realistic  scenarios.  Input  of  these  scenarios  may  be  automated  or  require  assistance  from 
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the  user  through  the  user  interface.  The  Device  &  Protocol  Database  will  provide  the  necessary  equipment  and 
protocol  models  necessary  to  run  the  simulation.  The  Thread/IER  Database  will  provide  the  traffic  and  operational 
procedure  models. 

The  Intelligent  Simulation  Interface  determines  what  simulators  are  necessary  to  run  the  simulation.  It  then 
coordinates  the  efforts  of  the  federation  of  simulators  in  order  to  provide  results  to  the  Performance  Evaluation 
portion  of  the  architecture.  Communications  between  federation  members  will  take  place  through  HLA  interfaces. 

The  Performance  Evaluation  process  takes  the  various  outputs  from  the  federation  and  converts  these  dissimilar 
results  into  coherent  and  compatible  Measures  of  Merit  (MoM).  If  GIESim  is  being  used  “in  the  loop”  by  a  force- 
level  simulations,  the  MoMs  can  be  sent  back  as  the  required  information  object.  For  off-line  simulations,  the  MoM 
may  be  used  to  created  high  fidelity  network  abstractions.  The  MoM  may  also  be  used  by  the  user  or  optimization 
routine  to  do  iterative  runs  of  the  simulation  for  optimization  purposes. 
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Figure  2-1.  GIESim  and  JBISim  Architecture 
2.3.3  Define  Roles  and  Interactions  of  the  Candidate  Simulation  Tools 

Figure  2-2  illustrates  several  GIESim  simulation  tools,  their  potential  interactions,  and  the  relative  user 
sophistication  required  to  effectively  operate  the  programs. 
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Figure  2-2.  Simulation  Tools  Interaction 

In  Figure  2-2  the  oval  shapes  represent  the  candidate  tools  and  ovals  nested  within  the  larger  ovals  indicate  tools  that 
are  subsets  of  the  larger  package.  For  example,  the  OPNET  Decision  Guru  is  an  OPNET  tool  that  offers  a  subset  of 
the  features  available  in  the  OPNET  program;  likewise,  the  OPNET  Development  Kit  (ODK)  is  a  development 
environment  that  may  or  may  not  use  features  of  the  OPNET  Modeler  program  to  implement  simulation  programs. 
The  height  and  vertical  position  of  the  oval  provides  an  indication  of  the  program’s  required  user  sophistication  to 
operate  the  program;  the  width  and  horizontal  position  of  the  oval  have  no  comparable  meaning. 

The  arrows  in  Figure  2-2  show  the  existing  (heavy  black)  and  possible  (dashed  black)  interaction  between  the  candidate 
programs.  For  example,  NETWARS  uses  the  OPNET  Modeler  program  (OPNET  add-on  modules)  for  processing;  in 
turn,  OPNET  Modeler  uses  an  STK  processing  kernel  for  mobile  communications  nodes.  As  indicated  by  multiple 
dashed  lines,  the  CAST  program  is  being  developed  to  provide  a  common  user  interface  to  multiple  simulation  and 
analysis  tools.  The  orange  arrows  indicate  that  the  NETWARS  and  CAST  tools  are  developed  using  ODK. 

2.4  GIESim  Phase  I  Recommendations 

The  Phase  I  GIESim  modeling  and  simulation  environment  tended  to  have  a  disconnect  between  force-level  and 
physics-based  simulations.  Force-level  simulations  generally  have  low  fidelity  models  to  represent  communications. 
Often,  the  force-level  simulations  assume  the  communications  always  work.  This  can  lead  to  invalid  simulations.  An 
example  would  be  an  air  asset  radioing  in  a  strike  message  against  an  enemy  target  without  a  high  fidelity  comm, 
simulation.  The  call  is  assumed  to  be  successful  and  the  target  would  be  destroyed.  However,  it  may  be  the  case  that 
a  high  level  comm,  simulator  would  show  that  terrain  would  block  the  strike  message.  This  would  change  the  results 
of  the  force-level  simulation  since  now  the  enemy  target  would  not  be  destroyed.  This  change  can  potentially  have  a 
large  domino  effect  on  the  force-level  simulation  as  it  continues  to  interact  with  the  simulation.  If  it  was  a  weapon 
system,  it  may  go  on  to  destroy  entities  that  would  not  have  otherwise  been  destroyed.  If  it  is  a  high  priority  target,  it 
may  cause  the  air  asset  to  change  course  in  order  to  ensure  that  the  strike  message  gets  through. 
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The  capabilities  to  model  the  necessary  communications  assets  exist  but  this  capability  has  not  been  integrated  in 
any  significant  way  with  force-level  simulations.  For  the  next  Phase  of  the  effort,  it  was  proposed  that  GIESim 
encompass  (see  Figure  2-3),  both  force-level  and  physics-based  simulations,  thereby  bridging  the  gap  and  melding 
the  capabilities  of  these  two  types  of  simulation. 
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Figure  2-3.  Force-level  and  Physics-based  Simulation 
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3.0 


GIESIM  PHASE  II 


3.1  GIESim  Phase  II  Goals 

The  primary  goal  of  this  effort  was  the  integration  of  communications  and  network  modeling  and  simulation  (M&S) 
toolkits  into  the  Global  Information  Enterprise  (GIE)  Modeling  and  Simulation  (GIESim)  framework  for  effective 
and  efficient  user  analysis  of  candidate  communications  architectures  and  technologies.  The  GIESim  is  a  simulation 
development  program  to  define,  design  and  implement  a  Modeling  and  Simulation  (M&S)  framework  for  GIE.  It 
was  developed  in  a  team  environment  that  brought  together  M&S  and  subject  area  expertise.  The  GIESim  team 
included  companies  and  Air  Force  (AF)  groups  with  the  experience  necessary  to  leverage  existing  experience  and 
emerging  communications  models.  The  GIESim  included  Air  Force  Research  Laboratory  (AFRL)  employees  at  the 
Rome  and  Wright  Patterson  Research  Sites,  large  and  small  companies,  and  academia. 

3.2  GIESim  Phase  II  Participants 

Air  Force  Research  Laboratory,  Information  Directorate,  Information  Grid  Division,  Distributed  Information 
Systems  Branch  (AFRL/IFGA)  has  provided  superior  management  and  leadership  to  the  GIESim  project  leading  to 
successful  project  R&D  technology  and  demonstrations.  IFGA’s  charter  is  to  identify  and  develop  technologies  to 
enable  a  distributed  information  infrastructure  that  provides  all  the  mechanisms  and  services  required  to  allow  the 
warfighters  to  craft  their  C4I  information  environments.  Specific  technologies  include:  network  protocols, 
information  adaptation,  network  management,  routing  technologies,  adaptive  interfaces,  distributed  information 
environments,  multimedia  services,  adaptive  security  services,  global  resource  management,  and  architectures. 

Prediction  Systems,  Inc.  (PSI)  has  been  involved  with  the  development  of  the  GIESim  project  in  all  phases  of  the 
effort.  PSI  provided  senior  software  engineering  staff  members  with  robust  knowledge  in  military  communications 
networking  including  Joint  Tactical  Information  Distribution  System  (JTIDS)  communication,  Department  of 
Defense  (DoD)  M&S,  High  Level  Architecture  (HLA),  GIESim  development,  integration  and  demonstration, 
development  of  force-level  and  tactical  communication  scenario  generation,  and  software  integration.  Also,  PSI  is 
the  developer  of  the  General  Simulation  System  (GSS)  which  provides  a  complete  facility  for  building  models  and 
running  simulations  of  general  dynamic  systems.  GSS  is  a  key  component  of  the  GIESim  software  architecture. 

Science  Applications  International  Corporation  (SAIC)  has  been  involved  with  the  development  of  the  GIESim 
project  since  its  inception.  SAIC  provided  senior  software  engineering  staff  members  with  hands-on  experience  and 
knowledge  in  DoD  M&S,  High  Level  Architecture  (HLA),  JSAF  software  development  and  integration,  GIESim 
development,  and  software  integration. 

Syracuse  Research  Corporation  (SRC),  like  PSI  and  SAIC,  has  been  involved  with  the  development  of  the  GIESim 
project  from  the  beginning.  SRC  has  provided  both  force-level  and  tactical  communication  scenario  generation 
development  with  staff  that  are  mission-specific  subject  matter  experts  having  served  within  the  Air  Force  and  other 
services.  SRC  has  provided  technical  management  direction  and  guidance  throughout  all  phases  of  the  GIESim 
development.  Having  technical  experience  with  OPNET  (a  network  simulation  tool)  SRC  aided  with  the 
development  of  the  successful  Scientific  Advisory  Board  (SAB)  related  tactical  demonstration  scenarios. 

3.3  GIESim  Phase  II  Accomplishments 

The  GIESim  Phase  II  Team  was  comprised  of  SRC,  SAIC,  PSI  and  AFRL.  The  following  tasking  activities  were 
achieved. 

•  Supported  AFRL  in  the  evaluation  of  communication  simulation  technologies  and  applications. 

•  Generated  realistic  scenarios  to  test  the  GIESim  architecture. 

•  Aided  AFRL  in  the  development  and  execution  of  the  GIESim  program  plan. 

•  Provided  direction  and  support  for  the  SAB  review. 
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The  paragraphs  to  follow  provide  details  on  the  tasking  activities  that  lead  up  to  the  SAB  presentation  and 
review  process. 

3. 3. 1  Technical  Exchange  Meeting 

SRC  led  organizing  the  Technical  Exchange  Meeting  (TEM)  in  AFRL  Building  3  on  May  14,  2003.  The  meeting 
was  attended  by  Dr.  Warren  Debany,  and  Richard  Smith  from  AFRL;  Marty  Ragusky,  Jim  Periard  and  Joe  Lauko 
from  SRC;  Jerry  Reaper  from  SAIC;  and  John  Fikus  from  PSI.  The  primary  area  of  discussion  centered  on  the 
Scientific  Advisory  Board  (SAB)  demonstration  and  the  planning  and  execution  necessary  to  reach  that 
demonstration.  Topics  covered  included  the  following  areas: 

•  Goals  &  Objectives 

•  SAB  Demo  Requirements 

-  Must  haves,  nice  to  haves 

-  Data  Collection  Requirements 

-  Analysis  plans 

-  Contingency  plan(s) 

-  Use  case  walk  through 

-  User  interface  (GSS,  MIST  STK,  etc.) 

•  Scenario  Requirements  (NE  Asia,  i.e.,  Korea  2010,  JBI  TCT) 

-  Must  haves,  nice  to  haves 

-  Required  behaviors  &  products  of  each  scenario  element  (e.g.,  what  the  JSTARS  does,  how  & 
why  it  does  it,  what  it  produces) 

-  Required  traffic  sources  and  patterns  GIESim  Architecture 

-  List  of  federates,  their  function  in  the  demo,  and  their  requirements 

-  Inputs/outputs 

-  Data  collection  requirements  collected 

•  Partitioning  of  scenario  responsibilities 

-  HLA  RTI-NG 

-  HLA  Federation  Object  Model  (FOM) 

-  User  interface  (GSS,  MIST  STK,  etc.) 

The  focus  of  the  meeting  was  to  kick  off  the  Phase  II  effort  which  was  centered  on  preparing  a  realistic 
demonstration  of  the  GIESim  capability  for  the  November  2003  SAB  visit  to  AFRL  Rome  Research  Site.  The 
simulation  approach  that  was  discussed  involved  integrating  the  following  tools  using  the  High  Level  Architecture 
(HLA)  backbone  interface  present  on  the  GIESim  and  the  JBI  Simulations.  Components  of  the  simulations  are  as 
follows: 


•  JBI  Simulation  from  AFRL 

•  OPNET  (ISR  Simulation)  from  SAIC 

•  GSS  (JTIDS)  and  STK  from  PSI 

The  demonstration  components  included  PSI’s  GSS/JTIDS  model.  This  offered  a  realistic  model  of  the  tactical 
network,  its  limitations,  and  capabilities.  Analytical  Graphics,  Inc.,  commercial  product,  STK,  was  used  to  model 
SATCOM  geometries.  The  OPNET  network  modeling  tool  to  do  an  ISR  simulation  that  SAIC  had  been  working 
and  the  Joint  Battlespace  Infosphere  (JBI)  simulation  to  help  manage  network  traffic. 

By  linking  these  products  the  GIESim  SAB  demonstration  would  show  message  traffic  going  from  ISR  platforms 
through  analysis  centers  to  command  and  control  platforms  and  finally  to  shooters  on  target.  The  message  traffic 
would  us  a  publishing/subscribing  protocol  in  JBI.  By  leveraging  the  GSS/JTIDs  simulation  analysis  could  be  done 
showing  limitations  in  the  communications  network  based  upon: 


•  Degradations  in  a  SATCOM  link 

•  bandwidth  limitations  (i.e.,  predator) 

•  Constellation  geometry  (satellites) 

There  was  also  discussion  related  to  who  was  going  to  use  GIESim  and  what  it  was  going  to  be  used  for.  The 
general  consensus  was  that  GIESim  is  a  framework  to  perform  analysis  or,  in  other  words,  a  tool  to  collect 
Measures  of  Performance  (MOP)  and  Measures  of  Effectiveness  (MOE)  for  different  communication 
configurations  and  parameters. 

3. 3.2  Technical  Exchange  Meeting  II 

A  second  Technical  Exchange  Meeting  (TEM)  was  held  on  June  19,  2003  to  further  define  what  was  to  be 
demonstrated  for  the  SAB.  The  highlights  of  the  meeting  were: 

•  SRC  led  a  discussion  on  CONOPS  and  Scenario. 

•  Prediction  Systems  Incorporated  briefed  their  GSS  modeling  tool  and  talked  about  the  GIESim 

Architecture. 

•  SAIC  talked  about  their  OPNET  modeling  efforts  and  how  it  fit  into  the  proposed  GIESim 

Architecture. 

•  AFRL  also  discussed  the  role  of  JBI  in  the  GIESim  demonstration. 

Some  of  the  fundamental  questions  discussed  at  the  TEM  were: 

•  Why  does  the  user  care  that  GIESim  exists? 

-  The  complex  communication  scenarios  that  GIESim  can  analyze  require  multiple  simulation 
applications  to  run  in  a  coordinated  fashion.  There  is  no  single  simulation  to  address  complex 
communication  issues  and  tradeoffs.  To  address  this,  GIESim  explored  architecture/ 
framework  options  for  integration  of  multiple  tools  capable  of  operating  at  multiple  fidelity 
levels. 

-  In  many  analyses  communication  bandwidth  and  connectivity  is  taken  for  granted.  GIESim 
provides  a  tool  to  add  the  detail  required  for  realistic  analysis.  Part  of  this  analysis  would 
include  latency  measurements  through  a  multi-level  communication  system. 

•  What  is  the  science  we  are  showing? 

-  Solving  complex  communications  problem  sets. 

•  Who  are  the  users? 

-  The  proposed  users  of  GIESim  are  Network  planners. 

•  What  problems  are  we  solving? 

-  Developing  complex  simulation  applications  is  very  expensive  and,  in  many  cases,  duplicates 
existing  efforts  with  slight  variations  to  address  specific  user  needs.  GIESim  reduces  the  cost 
of  simulation  by  developing  an  architecture/framework  for  the  integration  of  multiple  existing 
simulation  tools. 

-  GIESim  assists  in  the  planning  for  networking,  communications,  and  bandwidth  demands 
seen  in  complex  communication  scenarios. 

-  GIESim  also  provides  a  testbed  for  the  evaluation  of  JBI  infrastructure. 

The  components  of  Phase  II  GIESim  are  outlined  as: 

•  Joint  Battlespace  Infosphere  (JBI) 

-  JBI  defines  an  information  management  structure  for: 

•  Traffic  patterns  and  throughput  requirements 

-  Each  unit  has  defined  publish/subscribe  capabilities. 
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•  GSS  system  for  JTIDs  simulation. 

•  OPNET  to  be  used  to  simulate  Unmanned  Aerial  Vehicles  (UAV)  communication. 

•  STK  to  model  satellite  communication  asset  orbitology. 

Some  of  the  points  to  be  demonstrated  for  the  SAB  were  a  disruption  of  a  network  due  to  the  dropping  or  disruption  of 
a  communication  node.  After  disruption  GIESim  will  show  a  redistribution  of  traffic  and  provide  a  quick-look  analysis. 

The  proposed  GIESim  physical  architecture  was  designed  as  shown  in  Figure  3-1  below. 


Figure  3-1.  Proposed  GIESim  Physical  Architecture 


A  functional  representation,  shown  below  in  Figure  3-2,  was  also  discussed. 
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Figure  3-2.  Function  Representation 
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A  proposed  communication  scenario  to  show  to  the  SAB  was  also  presented  as  depicted  in  Figure  3-3.  The  scenario 
was  to  include  a  UAV  flying  over  Korea  reporting  data  (an  image)  back  to  a  CONUS  ground  exploitation  site.  After 
exploitation  at  the  ground  site,  information  is  forwarded  back  to  command  and  control  in  theater  and  subsequently 
on  to  a  shooter.  GIESim  would  demonstrate  the  limitations  of  the  communications  architecture  and  provide 
alternatives  and  tradeoffs. 


Figure  3-3.  Scientific  Advisory  Board  Preparation 


3.3.3  Bi-weekly  Teleconferences 

Starting  in  July  of  2003,  SRC  initiated  bi-weekly  teleconferences  to  discuss  the  demonstration  and  software 
preparation  for  the  scientific  board  presentation.  An  initial  development  schedule  was  proposed  as  follows: 


Initial  description  of  SAB  demo 

July  17 

GSS/OPNET  Integration  via  Internet  A 

July  24 

Revised  description  of  SAB  demo 

July  24 

GSS/OPNET  Integration  via  internet  B 

July  31 

Final  description  of  SAB  demo 

July  3 1 

Dry  run  SAB  demo  at  Rome 

Aug  7 

Final  pre-AFRL  dry  run 

Aug  21 

Demo  to  AFRL  for  SAB  decision 

Sept.  1 

Three  different  scenarios,  as  presented  in  Table  3-1  below,  were  proposed  and  worked  in  the  teleconferences. 
Scenario  2  was  selected. 
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Scenario  1 

Scenario  2 

Scenario  3 

Image  downlinked  to  AOC 
compound  at  Osan 

Image  downlinked  to  AOC  @ 

Osan 

Image  sent  from  UAV  to  Beale  via 
SATCOM  uplink 

Link  16  relay  from  control  van  to 
SATCOM  link 

Image  analysis  done  at  Osan 

Sent  to  Beale  via  SATCOM 

Image  analysis  done  @  Beale 

Link  1 6  relay  from  SATCOM  to 
AOC 

Strike  message  sent  from  AOC  to 
fighter  via  JTIDS 

Image  analysis  done  @  Beale 

Annotated  Image  from  Beale  to 

Osan  via  SATCOM 

Annotated  Image  from  Beale  to 

Osan  via  SATCOM 

Strike  message  sent  from  AOC  to 
fighter  via  JTIDS 

Strike  message  sent  from  AOC  to 
fighter  via  JTIDS 

Table  3-1.  SAB  Scenarios 


SRC  used  the  STK  to  prepare  mockups  of  the  scenarios  and  proposed  flight  paths  of  the  scenario  actors.  Figure  3-4 
shown  below  presents  the  UAV  flight  path  and  high  value  target  vehicle  track.  This  image  also  shows  the  Osan 
AOC  downlink  site  for  the  UAV. 


Figure  3-4.  UAV  Fight  Path  and  High  Value  Target 


The  second  image,  Figure  3-5  shows  the  connection  between  the  theater,  in  this  case  Korea,  and  two  CONUS 
exploitation  sites,  one  at  Beale  and  one  at  Langley.  The  connections  to  CONUS  require  SATCOM  to  be  employed. 
Beale  requires  a  single  satellite  connection  and  Langley  a  two-hop  connection. 
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Figure  3-5.  Korea  and  CONUS  Connectivity 


The  third  diagram,  Figure  3-6,  shows  a  3-D  view  of  the  satellite  configuration. 


Figure  3-6.  Three-D  View  of  Satellite  Configuration 


3. 3. 4  SAB  Posters 

GIESim  posters  were  also  developed  and  worked  in  the  teleconferences.  It  was  decided  that  three  posters  were  to  be 
made.  The  first  poster  Figure  3-7  below  outlines  the  GIESim  concept,  a  high  level  peek  at  a  CONOPS,  and  an 
overview  of  the  GIESim  framework. 
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Global  Information  Enterprise  Simulation  (GIESim) 

Purpose:  Support  Command  and  Control  Decision  Makers  in  Communications 
Planning  and  Analysis  for  future  Network  Centric  Operations 

Objective:  Develop  an  Advanced  Architecture  to  integrate  best  of  breed  COTS 
and  GOTS  tools  to  support  near  real-time  communication  solutions. 


Hypotheses 

•  Simulations  can  be  developed  in  hours  or 
days  versus  months 

•  Complex  communication  architectures  can 
be  quickly  simulated 

•  Multiple  levels  of  modeling  fidelity  can  be 
used  to  “drill  down”  into  areas  of  interest  & 
support  different  simulation  requirements 


GIESim  Backbone 


Challenges 


Current  state-of-the-art  enterprise 
level  communication  modeling 

•  Many  custom,  independent  niche  tools 

•  Requires  domain  experts,  lots  of  $  and  time 


The  GIESIM  Framework 

•  Intelligent  architecture  links  legacy  models 

•  Leverages  development  and  validation  dollars 

•  Best-of-breed  tools 

•  Model  selection  criteria  to  meet  user’s  needs 

•  Scenario  Development 


Decision  Support 

•  Network  Reconfiguration 

•  Reroute  traffic 

•  Add/Delete  Assets 

•  Quality  of  Service 


Figure  3-7.  GIESim  Concept 

The  second  poster,  Figure  3-8,  is  a  description  of  the  GIESim  scenario  demonstrated  for  the  SAB.  The  scenario  is 
described  from  three  view  points:  operational,  communications,  and  an  information  object  view. 
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First  Successful  GIESim  Prototype 

•  Complex  communication  architecture  .  Multiple  modeling  fidelities 

•  “Best-of-breed”  models 


Operational  View 


High  value  target  (HVT)  identified. 
UAV  follows  target  using  video. 
Images  sent  to  CONUS  via  SATCOM. 
Exploited  images  sent  to  AOC. 

Strike  command  to  fighter. 

Fighter  strikes  HVT. 


Communications  View 

Image  downlinked  to  control  van 
Image  sent  to  SATCOM  link  via  JTIDS 
Image  sent  to  Beale  via  SATCOM 
Image  analysis  done 
Annotated  Image  to  AOC  via  SATCOM 
Strike  message  to  C2  node  via  JTIDS 
C2  node  to  fighter  via  JTIDS 


Information  Object  View 


% 


Image  object  created,  destination 
exploitation  center 
Image  object  received 
Exploited  object  created,  destination 
AOC 


Cl) Strike  message  created,  destination 
fighter 


_ 

JBIsim 


STK’s  suite  of  tools  analyzes 
satellite  assets  and  orbits. 


GSS  is  a  visual  CAD 
environment  to  support 
Model  and  Scenario 
Development, 
Simulation  and 
Analysis. 


OPNET  is  a  discrete 
event  hierarchical 
network  simulator  with 
integrated  analysis  and 
animation  tools. 


GIESIM  Backbone 


Figure  3-8.  GIESim  Phase  II  Scenario  Description 

The  final  poster,  Figure  3-9,  discusses  proposed  GIESim  future  research  activities.  The  two  major  topic  areas 
discussed  in  the  final  poster  were  lessons  learned  and  future  research  areas.  The  lessons  learned  included: 

•  Order  of  magnitude  less  costly  to  leverage  existing  simulations.  GIESim  successfully  demonstrated  the 
analysis  of  a  complex  communications  architecture.  This  analysis  would  have  been  extremely  costly  if 
started  from  scratch.  By  leveraging  existing  simulation  technology  and  integrating  these  capabilities 
together,  a  useful  analysis  could  be  done  quickly  with  relatively  small  investment. 

•  Use  of  simulation  does  not  eliminate  the  need  for  subject  matter  experts.  The  use  of  the  leveraged 
simulations  and  GIESim  requires  someone  who  understands  communication  issues  and  real-world 
limitations. 

•  Components  require  tailoring  to  integrate  into  GIESim.  Much  of  the  effort  expended  was  spent 
customizing  the  existing  tools  to  fit  into  the  GIESim  architecture.  This  proved  relatively  inexpensive 
but  will  be  required  for  each  existing  technology  that  is  leveraged. 

•  Scenario  development  effort  should  not  be  underestimated.  The  development  of  a  realistic  scenario 
proved  non-trivial.  Even  though  the  basic  concepts  were  discussed  at  early  teleconferences,  a 
significant  amount  of  effort  was  expended  refining  the  scenario. 
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GIESim  Future  Research  Activites 


Lessons  Learned  (FY03) 

O  Order  of  magnitude  less  costly  in  dollars  and 
time  to  leverage  existing  simulations 
•  Use  of  existing  simulations  does  not  eliminate  the 
need  for  domain  experts 

O  Model/components  require  tailoring  to  integrate 
into  GIESim 

©  Scenario  development  complexity  should  not  be 
underestimated 


Vision 


Future  Research  Areas 

©Explore  Customer/System  Needs 
©  Reduce  the  dependency  on  domain  experts 
©Techniques  to  Speed-up  Multi-Sim  Development 
©  Innovative  Methods  to  Improve  Sim  Architecture 

•  HLA  Protocol 

•  Web  Services 

•  Collaborative  Environments 

©  Standard  Definition  of  Simulation  Scenario 

•  Communication  Topology 


FY04  Lab/Demo  Activities 
GIESim  Lab  Development 

•  Develop  GIESim  multi-simulation  lab 

Demonstration  Phase 

•  Develop  DTIG  Scenario 

•  Demonstrate  Deployed  Theater  Information  Grid 
(DTIG)  in  Multi-Simulation  GIESim  Environment 


Figure  3-9.  GIESim  Future  Research  Activities 


3.3.5  SAB  Summary 

The  GIESim  Phase  II  effort  focused  on  producing  a  demonstration  capability  for  the  Scientific  Advisory  Board 
(SAB).  The  GIESim  Team  worked  closely  to  define,  develop,  and  deliver  a  successful  demonstration;  the  SAB 
members  responded  favorably  to  the  GIESim  concept.  During  this  phase  of  the  effort,  SRC  provided  assistance  to 
AFRL  with  scenario  design  and  development,  Concept  of  Operation  (CONOP)  development,  and  the  overall 
management  of  the  software  development  efforts. 

3.4  GIESim  Phase  II  Recommendations 

As  stated  and  presented  at  the  SAB,  several  GIESim  future  research  areas  were  discussed  and  recommended.  These 
recommendations  are: 

•  Explore  customer/system  needs 

•  Reduce  dependences  on  domain  experts 

•  Develop  techniques  to  improve  simulation  architecture 

-  HLA  Protocol 

-  Web  Services 

-  Collaborative  Environments 

•  Standardize  simulation  scenario  definition 

-  Communications  topology 
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4.0  GIESIM  PHASE  III 


4.1  GIESim  Phase  III  Goals 

The  primary  goal  of  GIESim  Phase  III  was  the  merging  of  the  GIESim  JTIDS  simulation  with  AFRL/IFGA  Joint 
Semi-Automated  Forces  (JSAF)  project.  The  GIESim  JTIDS  added  tactical  communications  modeling  to  JSAF. 
Also,  the  merger  of  the  JTIDS/Fink-16  capabilities  from  GIESim  with  JSAF  was  a  first  step  toward  applying  the 
GIESim  rapid  communications  modeling  approach  to  a  large  simulation  environment.  Of  equal  importance  in 
GIESim  Phase  III  was  the  Modeling  and  Simulation  (M&S)  demonstration  between  JSAF  and  GIESim  JTIDS  that 
tested  their  interoperation  and  had  an  impact  on  an  observer.  Eastly,  an  operational  relevant  scenario  was  developed 
to  successfully  demonstrate  the  value  of  adding  communication  modeling  to  the  JSAF  program. 

4.2  GIESim  Phase  III  Participants 

The  GIESim  Phase  III  effort  focused  on  the  integration  of  GIESim  communication  simulation  software  with  the 
Joint  Semi- Automated  Forces  (JSAF)  simulation  software.  To  help  keep  continuity  of  the  program,  the  Modeling 
and  Simulation  team  of  SRC,  SAIC,  PSI,  and  AFRF/IFGA  continued  to  work  closely  on  this  final  stage  of  the 
effort.  SRC  continued  to  provide  both  force-level  and  tactical  communication  scenario  generation  development. 
The  staffs  assigned  to  the  program  were  mission- specific  subject  matter  experts  having  served  within  the  Air  Force 
within  key  intelligence  gather  and  analysis  areas.  Also,  PSI  continued  to  provide  senior  software  engineering  staff 
members  with  robust  knowledge  in  military  communications  networking,  DoD,  M&S,  HFA,  GIESim  development, 
integration  and  demonstration,  development  and  force-level  and  tactical  communication  scenario  generation,  as  well 
as  software  integration.  SAIC  provided  additional  stability  to  the  effort  with  GIESim  experienced  senior  software 
engineering  staff  members  with,  hands  on  and  knowledge  in  DoD  M&S,  HFA,  and  comprehensive  knowledge  of  the 
JSAF  software  development  and  integration  program. 

4.3.  GIESim  Phase  III  Accomplishments 

Figure  4-1  represents  the  GIESim/JSAF  merger  requirements^  and  the  steps  that  the  GIESim/JSB-RD  team  took  in 
integrating  the  GIESim  and  JSB-RD  software  suites.  This  diagram  was  created  to  assist  the  team  in  maintaining 
focus  on  the  sub-tasking  that  we  had  to  follow  to  achieve  this  goal.  The  merger  requirements  were  determined  over 
several  face-to-face  team  telecommunication  meetings  and  e-mail  exchanges.  For  the  merger,  this  meant 
maximizing  re-use  of  prior  investments  to  minimize  new  developments  and  to  speed  realization  of  the  merger,  as 
well  as  starting  with  a  simple,  though  effective,  scenario. 


Simulation  Players  Simulation  Entities  HLA  Com  Hooks  Force  Deployment(s)  JTIDS  Networks  Interoperability  Tests 

-  Roles/Responsibilities  -  Behaviors  by  Sim  Com  Strategies  Movement  Paths  Other  Networks  Metrics  Analysis 

Physical  Interfaces  Coupling  bt.  Sims  Interfaces  Mission  Goals  Demo 


Figure  4-1.  Steps  for  GIESim/JSB-RD  Software  Merger 
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4.3.1  Physical  Architecture  (Step  # 1 ) 


To  establish  the  physical  architecture,  the  merger  team  had  to  select  from  several  available  GIESim  components. 
Given  that  tactical  communications  was  the  most  important  component  to  add  to  JSAF,  the  team  chose  to  use  the 
JTIDS  simulation  from  GIESim.  This  simulation  would  be  interfaced  to  the  main  component  of  JSAF.  This 
relationship  is  shown  in  Figure  4-2. 


Figure  4-2.  GIESim-JSAF  Physical  Architecture 


Given  that  JSAF  traditionally  handles  platform  motion,  we  determined  that  JSAF  would  retain  this  role,  whereas  the 
JTIDS  simulation  would  provide  tactical  communications  modeling. 

4.3.2  Logical  Architecture  (Step  #2) 

Step  2  was  determination  of  the  logical  architecture  of  the  merger.  This  entailed:  1 .)  an  analysis  of  the  capabilities  of 
JTIDS  and  the  associated  Fink- 16  message  set,  2.)  an  exploration  of  the  “messaging”  capabilities  inherent  to  JSAF, 
and  3.)  behavioral  relationships  between  JTIDS  simulation  and  JSAF.  We  had  to  consider  the  types  of  scenarios  and 
missions  that  might  be  supported  and  the  volume  of  High  Fevel  Architecture  (HE A)  traffic  that  might  be  generated. 
The  general  view  that  developed  was  that  platform  entities  would  communicate  within  JSAF  by  sending 
transmission  requests  to  the  JTIDS  simulation  which,  in  turn,  would  provide  a  response  if  the  target  platform 
received  the  transmission.  Approximately  40%  of  the  Fink- 16  messages  support  destination  addressing,  so  we 
agreed  to  provide  a  single  address  field  in  the  transmission  requests  from  JSAF  to  the  JTIDS  simulation.  Fink- 16 
also  supports  “broadcast”  addressing,  so  we  agreed  to  support  a  broadcast  mode  for  future  use.  The  team  also  agreed 
to  initially  limit  the  types  of  message  transmissions  to  Command  and  Control,  Mission  Management,  Mission 
Status,  and  Threat  Warning  messages  as  these  were  deemed  more  “mission  critical.” 

Both  the  JTIDS  simulation  and  JSAF  required  enhancements  to  support  this  logical  architecture  (Figure  4-3).  In 
addition,  corresponding  platform  entities  would  have  to  exist  in  both  JTIDS  and  JSAF  so  there  was  a  need  for  a 
common  reference  mechanism  for  referencing  platforms  across  the  simulations. 


Enhanced  JSAF  Enhanced  JTIDS 


XT  01(1 

New  _  ... 

_  ...  Position 

Position 

GIESim 

ENTITY_STATE 

Message 

Updated  Current 

Position  T  Position 

Jf" 

nC _ 2 

Flight  Path 

w 

Virtual  Flight  Path 

JTIDS  Driver 
“JSAF  Surrogate” 


Map  Entity  ID  Numbers 


Figure  4-3.  JSAF  Platform  Position  Updates  into  JTIDS 
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4.3.3  Simulation  Interfaces  (Step  #3) 

In  Step  3,  the  merger  team  faced  several  trade-offs  in  development  of  the  simulation  interface.  Both  JSAF  and 
GIESim  used  HLA.  However,  JSAF  used  Run  Time  Infrastructure  (RTI-s)  whereas  GIESim  used  the  Defense 
Modeling  and  Simulation  Office  (DMSO)  RTI.  Given  that  JSAF  has  a  huge  software  base,  it  seemed  more  cost- 
effective  for  GIESim  to  move  to  RTI-S.  This  was  more  challenging  than  initially  expected.  To  support  messaging 
between  JSAF  and  JTIDS,  the  merger  team  agreed  to  use  modified  versions  of  the  HLA  interactions  that  were 
developed  for  inter-simulation  communication  by  the  GIESim  team.  However,  JSAF  was  already  using  the 
Millennium  Challenge  02  (MC02)  HLA  FOM  and  used  HLA  Objects.  This  required  a  merger  of  these  FOMs  into  a 
new  FOM  that  became  known  as  MC02plus.  JSAF  also  had  to  make  some  conversion  between  HLA  Objects  and 
HLA  Interactions  to  support  the  merger  interface.  Both  GIESim  and  JSAF  needed  to,  and  eventually  did,  confirm 
correct  operation  with  the  MC02plus  FOM. 

Figure  4.3  illustrates  how  JSAF  sends  platform  position  updates  to  the  JTIDS  simulation.  Platform  positions  are 
critical  in  the  JTIDS  simulation  for  RF  propagation  calculations.  A  GIESimENTITYSTATE  HLA  interaction  is 
used  that  contains  the  platform  entity  ID,  LAT  LON  position,  altitude,  and  heading.  The  entity  ID  is  a  unique 
number  for  each  platform  in  the  scenario  that  gets  mapped  to  a  simulation-specific  internal  platform  reference.  This 
interface  mapping  approach  allows  each  simulation  to  retain  its  own  internal  platform  references.  The  merger  team 
agreed  that  the  JTIDS  simulation  would  generate  a  hash  file  for  use  in  JSAF.  Note  that  a  JTIDS  Driver  simulation 
was  built  that  served  as  a  surrogate  for  JSAF.  This  simulation  proved  invaluable  in  early  testing  of  the  enhanced 
JTIDS  simulation  and  helped  to  isolate  problems  that  occurred  in  early  interoperability  testing. 

Figure  4-4  illustrates  a  message  transmission  request  from  JSAF  to  JTIDS.  JSAF  sends  a  GIESIM  MSG  SEND 
HLA  interaction  with  the  sending  and  destination  platform  entity  IDs,  a  JSAF  message  ID  number  and  size,  and  a 
Net  Type  Number.  See  next  section  for  details.  If  JTIDS  can  find  an  appropriate  network,  it  will  send  the  message. 
If  the  destination  platform  receives  the  message,  JTIDS  will  send  JSAF  a  GIESIMMSGRCVD  HLA  interaction 
with  the  destination  entity  ID,  JSAF  message  ID,  and  accumulated  latency. 

Tactical  communications  may  fail  due  to  interference,  distance,  etc.  Therefore,  the  merger  team  needed  to  determine 
how  to  handle  this.  Figure  4-5  shows  handling  of  successful  communications  and  communications  failure.  The  top 
part  of  the  figure  shows  successful  communications.  JSAF  builds  a  message  that  is  intended  for  a  specific  platform. 
Rather  than  sending  the  actual  message  to  JTIDS,  JSAF  sends  the  message  ID  and  its  size  to  JTIDS  with  the 
appropriate  addressing,  etc.  When  the  target  platform  receives  the  message  in  the  JTIDS  simulation,  the  simulation 
then  sends  a  response  to  JSAF  with  the  platform  entity  ID  and  JSAF  message  ID.  JSAF  then  processes  the  message 
and  takes  some  action. 


Communications  Enhanced  Enhanced 

JSAF  JTIDS  Simulation 


GIESIM MSG S 

END 

.  Transmit 

^  \w  on  selected 

CrVips  ^  Network 

GIESIM. 

MSG_RCVD 

Figure  4-4.  Message  Transmission  Request  and  Response 

When  a  transmission  is  lost,  JTIDS  does  not  send  a  response  to  JSAF.  This  is  how  communications  work  in  the 
physical  world.  JSAF  either  times  out  or  makes  several  retransmission  attempts1. 


1  J.  Reaper,  et.al.[1],  describes  JSAF  message  handling  in  the  companion  to  this  paper. 
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Figure  4-5.  Communications  Message  Handling 
4.3.4  JTIDS  Simulation  Model  Enhancements 


The  GIESim  JTIDS  simulation  was  modified  to  support  operation  with  JSAF,  which  involved  position  updates  and 
transmission  requests  from  JSAF  and  message-received  responses  to  JSAF[4][5]. 

Position  Updates:  The  original  JTIDS  simulation  dynamically  updated  platform  positions  from  its  own  scenario 
file.  To  support  platform  updates  from  JSAF,  models  were  added  to  take  platform  position  updates  externally  over 
HFA.  The  GIESIMENTITYSTATE  HLA  interaction  was  used  to  supply  the  update  data,  and  Table  4-1  shows 
the  parameters  for  this  HLA  interaction  within  the  JTIDS  simulation.  JSAF  filled  in  the  values  for  Entity  ID, 
platform  heading,  platform  position  in  the  form  of  LAT  LON  data,  and  platform  altitude.  The  other  parameters  were 
not  used. 


GIESIM  ENTITY  STATE  HLA  Interaction 


ENTITY_TYPE_DETAIL 
1  ENTITY_TYPE  CHAR 
1  DOMAINX  CHAR 
1  COUNTRY_CODE  INDEX 
1  CATEGORY  CHAR 
1  SUBCATEGORY  CHAR 
ENTITY_ID_DETAIL  INDEX 
HEADING_DETAIL  REAL 
WORLD_LOC AT I ON_D AT A 
1  LAT  REAL 

1  LON  REAL 

1  ALT  REAL 

SPECIAL  EFFECTS  DATA  INTEGER 


Table  4-1.  Communications  Message  Handling 

Entity  IDs:  JSAF  and  the  JTIDS  simulations  each  use  their  own  representation  of  platforms  and  platform  IDs. 
Rather  than  make  substantive  changes  to  either  simulation,  the  merger  team  agreed  to  use  a  common  set  of  platform 
reference  numbers  or  Entity  IDs  when  exchanging  HLA  interactions.  Each  simulation  would  map  an  Entity  ID  to  or 
from  its  own  reference  to  a  particular  platform.  The  team  agreed  to  use  the  unique  Entity  ID  numbers  produced  by 
the  JTIDS  simulation.  Hashing  the  platform  names  used  in  the  JTIDS  scenario  file  generated  these  numbers. 

Transmission  Request  &  Response:  The  area  of  greatest  change  in  the  merger  was  message  handling  in  both 
simulations.  The  JTIDS  simulation  was  designed  to  internally  send  messages  to  gather  performance  data  on  the 
quality  of  network  designs.  For  the  GIESim  project,  modifications  had  been  made  to  the  JTIDS  simulation  to  allow 
certain  messages  to  pass  through  the  simulation.  To  support  JSAF,  however,  the  JTIDS  simulation  messaging 
capabilities  had  to  be  generalized  and  significantly  expanded. 
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JTIDS  uses  many  networks  between  groups  of  platforms.  Each  network  serves  a  specific  purpose  and  satisfies 
specific  communications  requirements.  While  there  are  many  networks,  there  is  usually  a  small  collection  of 
network  types ,  e.g.,  mission  management  networks  vs.  threat  warning  networks.  The  merger  team  agreed  to  assign  a 
net  type  number  to  each  category  of  networks.  The  enhanced  JTIDS  simulation  outputs  a  NETMAPFILE  file  such 
that  JSAF  can  reference  the  type  of  network  needed  for  a  message  transmission.  This  approach  attains  a  certain 
amount  of  useful  decoupling  between  JSAF  and  JTIDS. 

Figure  4-6  illustrates  the  transmission  message  handling  in  the  enhanced  JTIDS  simulation.  When  JTIDS  receives  a 
GIESIM  MSG  SEND  interaction,  it  first  attempts  to  map  the  entity  IDs  for  the  source  and  destination  platforms  to 
internal  values.  Transmission  requests  drop  if  IDs  are  bad.  If  entity  mapping  is  successful,  then  JTIDS  takes  the 
NET  Type  number  and  looks  up  the  associated  text  description.  JTIDS  then  attempts  to  find  a  net  based  on  the 
source  and  destination  platform  and  the  network  description.  If  an  appropriate  net  is  found,  then  JTIDS  puts  the 
JSAF  message  ID  and  incoming  latency  into  the  JTIDS  message  payload.  If  the  JSAF  message  size  fits  into  the 
capacity  of  the  selected  network,  it  is  sent  as  a  single  message.  If  the  JSAF  message  is  too  big  for  the  network,  then 
JTIDS  performs  message  segmentation  and  sends  multiple  segments.  At  the  receiving  end,  segments  are 
reassembled.  When  a  whole  message  has  been  received  successfully,  JTIDS  builds  a  GIESIMMSGRCVD 
response  message  that  includes  the  entity  ID  of  the  destination  platform,  accumulated  latency  and  JSAF  message  ID. 


Figure  4-6.  Enhanced  JTIDS  Message  Handling 


Several  models  and  processes  within  the  JTIDS  simulation  had  to  be  modified  and  enhanced  to  support  simulation 
interfacing  with  JSAF.  One  of  the  most  significant  changes  was  the  addition  of  the  JSAF  “payload”  to  the  internal 
data  structures  in  the  simulation.  This  change  percolated  through  many  parts  of  the  JTIDS  simulation. 


The  move  from  the  DMSO  RTI  to  RTI-S  in  the  JTIDS  simulation  turned  out  to  be  challenging  as  stated  above.  The 
JTIDS  simulation  was  built  and  maintained  with  the  General  Simulation  System  (GSS®)[6][7].  GSS  is  a  high 
performance,  rapid  development  language  and  environment  developed  by  PSI  for  building  models  and  running 
simulations  and  planning  tools.  Due  to  library  name  changes  in  RTI-S,  a  few  minor,  though  tricky,  modifications 
were  needed  in  GSS  for  the  JTIDS  simulation  to  run  with  RTI-S.  Also,  while  RTI-S  seems  more  robust  than  the 
DMSO  RTI,  it  performs  a  check-sum  on  the  FED  files,  which  requires  all  FED  files  to  match.  The  DMSO  RTI 
allowed  each  simulation  to  use  subsets  of  a  larger  FOM. 


As  mentioned  earlier,  PSI  built  a  modified  version  of  JTIDS  to  serve  as  a  Driver  surrogate  for  JSAF.  This  Driver 
simulation  can  send  platform  position  updates  automatically  or  manually,  and  can  manually  formulate  message 
transmission  requests.  The  Driver  was  invaluable  for  early  testing  of  the  enhanced  JTIDS  simulation  for  JSAF,  and 
for  exploring  early  interoperability  problems  with  JSAF.  The  Driver  also  allowed  testing  and  refinement  of 
scenarios  and  networks. 


4.3.5  Scenario  Design  and  Mission  Goals  (Step  # 4 ) 

Scenario  development  is  one  of  the  more  challenging  aspects  for  any  distributed  simulation  environment.  Figure  4-7 
illustrates  the  layers  of  scenario  development  that  the  merger  team  considered  while  building  the  scenario  for  the 
initial  GIESim-JSAF  interoperability  testing  and  demonstration. 
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Figure  4-7.  Hierarchical  Layers  in  Scenario  Development 

The  dynamic  operational  scenario  proved  to  be  more  of  a  challenge  because  the  merger  team  wanted  a  scenario  that 
was  simple  but  operationally  relevant,  had  visual  impact,  and  could  run  fast  enough  for  an  effective  demonstration. 
Therefore,  the  team  agreed  to  use  the  Korean  theater  for  the  area  of  operation  since  this  was  currently  used  by 
GIESim  and  was  readily  available  to  the  JSB-RD  team  for  JSAF. 

The  scenario  that  became  accepted  involved  a  Special  Operations  Force  (SOF)  on  the  ground  that  observes  a  Time 
Sensitive  Target  (TST).  A  tactical  F-15  STRIKER2  aircraft  receives  a  target  message  from  the  SOF  and  follows 
terrain  during  ingress  to  the  target.  Later  on,  the  SOF  detects  a  mobile  SAM  site  and  attempts  to  warn  the  incoming 
STRIKER.  However,  the  SOF  is  now  separated  from  the  STRIKER  by  a  mountain  ridge.  The  overall  scenario 
became  known  as  the  “Wow”  scenario.  A  screenshot  of  this  scenario  is  shown  in  Figure  4-8  at  the  point  where  the 
F-15  is  following  terrain  through  a  valley  towards  the  target.  There  are  three  variations  to  the  scenario  that  are 
intended  to  demonstrate  the  importance  of  tactical  communications. 

Scenario  1  -  JSAF  Only:  The  SOF  “notifies”  the  STRIKER  who  evades  the  SAM.  The  STRIKER 
survives. 

Lesson:  The  simulation  is  unrealistic,  and  worse,  it  erroneously  predicts  the  STRIKER  gets  away . 

This  is  not  acceptable  for  realistic  simulation  planning  -people  can  get  killed . 

Scenario  2  -  JSAF  w /  Comms  but  no  Relay:  The  SOF  uses  JTIDS  to  send  a  threat  warning  to  the 
STRIKER  but  the  mountain  range  blocks  direct  radio  contact.  The  STRIKER  gets  hit. 

Lesson :  We  need  to  account  for  distance,  terrain,  and  network  design  in  realistic  mission  planning! 


2 

The  term  STRIKER  is  used  to  refer  to  tactical  aircraft  with  the  mission  assignment  of  striking  a  target. 
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Scenario  3  -  JSAF  w/Comms  and  Relay:  Based  on  the  results  of  the  prior  run,  we  turn  on  a  JTIDS  relay 
on  a  UAV.  Now  the  STRIKER  gets  the  relayed  threat  warning  and  evades! !  The  STRIKER  gets  away . 
Lesson :  Communications  modeling  and  advanced  planning  in  support  of  operations  is  critically  important! 

Because  the  simulation  detected  communications  failure,  required  adjustments  could  be  made  to  the 
deployment  and  network  design  to  ensure  success  of  the  mission. 


The  flight  path  of  the  F-15  STRIKER  aircraft  is  shown  in  Figure  4-8.  Crosses  along  the  path  indicate  waypoints. 
The  SOF  is  in  the  upper  right  near  the  TCT  (red  square)  and  pop-up  threats  (crosses).  The  UAV  in  the  upper  left 
follows  a  flight  path  that  keeps  it  near  the  area  of  operation.  The  F-15  has  entered  the  valley  on  its  way  to  the  target. 
The  heavy  dotted  line  indicates  that  direct  communications  with  the  SOF  are  broken  due  to  the  mountain  range.  The 
other  heavy  lines  indicate  good  network  connection  between  the  UAV  and  the  F-15  and  to  the  SOF.  Additional 
details  on  the  design  of  the  “Wow”  scenario  and  its  associated  JTIDS  networks  are  discussed  in  the  next  section. 


Direct  OK 
Direct  NG 
Relay  OK 
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Figure  4-8.  SOF,  STRIKER,  UAV  Relay,  Time  Sensitive  Target,  and  Threats  in  the  66 Wow”  Scenario 


4.3. 6  Planning  and  Network  Design  (Step  #5) 

The  “Wow”  scenario  was  designed  using  the  Fink- 16  Planning  Tool.  This  planning  tool  is  part  of  a  Fink- 16 
Network  Management  System  (NMS)[8]  designed  and  built  by  PSI  for  the  Air  Force.  It  is  important  to  note  that  the 
PSI  Fink- 16  NMS  illustrated  in  Figure  4-9  was,  and  continues  to  be,  critically  important  to  the  success  of  the 
GIESim/JSB-RD  software  merger.  The  Fink- 16  Planning  Tool  was  used  to  define  the  initial  scenario  and  all  Fink- 
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16  Networks  used  in  the  merger;  the  enhanced  version  of  the  Link-16/JTIDS  Simulation  is  the  tactical 
communications  component  that  we  added  to  JSAF. 


PSI  Link-1 6/JTIDS  Network  Management  System 


Figure  4-9.  PSI  Link-16  Network  Management  System 

The  screenshot  of  the  “Wow”  scenario  in  Figure  4-8  was  taken  from  the  Link- 16  Planning  Tool.  We  first  used  the 
tool  to  determine  the  best  location  for  the  “Wow”  scenario,  then  built  a  flight  path  for  the  F- 15  that  started  high  and 
then  dropped  to  follow  terrain  through  the  valley  leading  to  the  target.  We  also  positioned  the  UAV  relay  such  that 
RF  links  were  always  available  to  the  SOF  and  to  the  F-15.  We  then  “captured”  the  network  requirements  for  the 
“Wow”  scenario  that  had  been  agreed  to  by  the  team.  Three  networks  were  defined,  as  shown  in  Table  4-2. 


Net  Purpose/Label 

Net  Type  # 

Link-16  Msg 

Source 

Destination 

Access  Mode 

Response  Time 

Threat  Warning 

14 

J15.0 

SOF 

F-15 

Dedicated 

1  Sec 

Mission  Control 

15 

J12.7 

SOF 

F-15 

Dedicated 

2  Sec 

Engagement  Status 

16 

J12.6 

F-15 

SOF 

Contention 

2  Sec 

Table  4-2. 66 Wow”  Scenario  JTIDS  Networks 


JTIDS/Link-16  is  the  preeminent  tactical  waveform  today,  and  is  the  most  complex.  JTIDS  uses  a  mix  of  Time 
Domain  Multiple  Access  (TDMA),  Frequency  Domain  Multiple  Access  (FDMA),  and  Collision  Detection  Multiple 
Access  (CDMA),  and  therefore  requires  that  networks  be  custom  designed  to  support  all  platform  communications 
requirements.  The  term  “design”  refers  to  allocation  and  assignment  of  appropriate  time  slots,  which  has  been  a 
complex  and  time  consuming  process.  The  PSI  Link- 16  NMS  automates  the  time  slot  allocation  process.  As  shown 
in  Figure  4-9,  the  Link- 16  NMS  has  a  Generic  Requirements  Database  manager  that  is  used  to  define  “generic” 
requirements.  The  Planning  Tool  is  used  to  build  dynamic  scenarios,  to  capture  and  refine  network  requirements, 
and  can  launch  the  Automatic  Allocation  and  Assignment  Tool,  which  automates  time  slot  allocation  in  minutes. 
The  completed  scenario  and  network  design  are  fed  into  the  JTIDS.  Link- 16  Simulation  to  assess  network  design 
performance  by  passing  message  traffic  between  Link- 16  equipped  platforms  as  they  move.  The  data  for  the  “Wow” 
scenario  was  exported  and  then  imported  into  JSAF. 

Key  characteristics  of  the  PSI  Link- 16  Network  Management  System  include: 

•  Rapid  generation  of  complex,  dynamic  scenarios  against  terrain. 

•  Accurate  and  fast  radio  propagation  models  that  use  3-D  terrain  data,  the  effects  of  transmitter  power 
and  antenna  types,  and  that  account  for  mutual  interference  and  noise  sources. 

•  Ability  to  visualize 
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-  2-D  and  3-D  terrain  and  terrain  contours  plus  political  boundaries. 

-  Movement  paths  and  platform  motion  along  the  paths. 

-  Dynamic  RF  link  connectivity  between  platforms. 

-  Network  requirements  (including  relays)  that  are  either  satisfied  or  unsatisfied. 

•  Ability  to  capture  and  refine  network  requirements  and  automation  of  time  slot  allocations. 

•  Ability  to  simulate  message  traffic  by  events  in  dynamic  scenarios. 

•  Ability  to  dynamically  assess  network  performance. 

•  Supports  rapid  iterative  design  and  refinement  of  mission  scenarios  and  network  designs. 

•  Enhanced  interface  to  JSAF  for  external  position  updates,  handling  of  network  transmission  requests, 
and  notification  of  received  messages. 

PSI  has  used  the  Link- 16  NMS  to  design  scenarios  and  networks  of  much  greater  complexity. 

4.3. 7  Component  Integration  (Step  #6) 

Figure  4-10  illustrates  the  integration  of  the  JSAF  and  JTIDS  simulation.  The  common  scenario  contains  both  the 
force  deployments  and  their  associated  movement  paths.  The  initial  version  of  this  common  scenario  was  developed 
in  the  Link- 16  Planning  Tool.  Each  simulation  environment  then  codifies  the  scenario  for  its  force  deployment. 
Movement  paths  are  imported  into  JSAF.  Based  on  the  force  deployment,  the  JTIDS  simulation  generates  an  Entity 
Map  file  that  JSAF  uses  to  encode  platform  references  to  JTIDS.  JTIDS  reads  in  the  network  file  that  contains 
requirements  and  actual  network  designs,  i.e.,  time  slot  allocations,  and  generates  a  Net  Types  file  that  JSAF  uses  to 
specify  a  network  in  a  transmission  request.  Both  simulations  use  the  MC02plus  FOM.  Once  both  simulations  are 
started,  JSAF  sends  position  updates  to  JTIDS,  and  makes  message  transmission  requests. 


Figure  4-10.  Integration  of  JSAF  and  JTIDS  Simulations 


We  faced  several  operational  challenges  in  getting  the  two  systems  to  integrate,  which  took  longer  than  expected. 
Challenges  fell  into  two  main  categories:  physical  interoperability  and  scenario  interoperability. 


Initially,  the  move  to  RTI-S  caused  some  delay  in  the  JTIDS  simulation,  which  was  discussed  earlier.  Face-to-face 
lab  time  was  limited  because  the  merger  team  was  split  over  three  distant  geographical  locations.  One  remote  site 
did  not  have  Linux  or  JSAF;  the  nature  of  RTI-S,  firewalls,  and  security  concerns  ruled  out  testing  over  the  Internet. 


25 


The  ability  to  visualize  scenarios  in  both  JSAF  and  the  JTIDS  simulation  helped  immensely.  Also,  the  ability  to 
manually  construct  and  examine  messages  in  both  simulations  proved  to  be  invaluable.  For  the  JTIDS  simulation, 
manual  message  construction  and  examination  were  a  legacy  of  prior  GIESim  work.  Background  diagnostic 
messages  also  facilitated  rapid  resolution  of  minor  interoperability  issues. 

Scenario  interoperability  refers  to  the  ability  to  achieve  the  simulation  results  expected.  Recall  that  the  original 
“Wow”  scenario  was  designed  with  the  Link- 16  NMS  planning  tool.  Scenario  data  was  imported  into  JSAF  where 
minor  changes  occurred,  such  as  the  position  of  the  SOF.  Also,  in  a  desire  to  shorten  the  demonstration  run  time,  the 
flight  path  of  the  F-15  was  shortened.  In  radio  communications  at  1  GHz  (the  operating  frequency  of  JTIDS)  minor 
position  changes,  particularly  of  ground  radios  in  heavy  terrain,  can  impact  connectivity.  These  minor  differences 
were  quickly  corrected.  Interoperability  success  was  finally  achieved,  and  the  team  is  now  looking  to  apply  the 
merged  software  to  larger  scenarios. 

4.4  GIESim  Phase  III  Operation  Scenarios 

The  dynamic  operational  scenario  proved  to  be  more  of  a  challenge  as  the  merger  team  required  a  scenario  that  was 
simple  but  operationally  relevant,  had  visual  impact,  and  could  run  fast  enough  for  an  effective  demonstration. 
Therefore,  the  team  agreed  to  use  the  Korean  theater  for  the  area  of  operation  since  this  was  currently  used  by 
GIESim  and  was  readily  available  to  the  JSB-RD  team  for  JSAF. 

The  scenario  that  became  accepted  involved  a  Special  Operations  Force  (SOF)  on  the  ground  that  observes  a  Time 
Sensitive  Target  (TST).  A  tactical  F-15  STRIKER3  aircraft  receives  a  target  message  from  the  SOF  and  follows 
terrain  during  ingress  to  the  target.  Later  on,  the  SOF  detects  a  mobile  SAM  site  and  attempts  to  warn  the  incoming 
STRIKER.  However,  the  SOF  is  now  separated  from  the  STRIKER  by  a  mountain  ridge.  The  overall  scenario 
became  known  as  the  “Wow”  scenario.  A  screenshot  of  this  scenario  is  shown  in  Figure  4-11  at  the  point  where  the 
F-15  is  following  terrain  through  a  valley  towards  the  target.  There  are  three  variations  to  the  scenario  that  are 
intended  to  demonstrate  the  importance  of  tactical  communications. 

Scenario  1  -  JSAF  Only:  The  SOF  “notifies”  the  STRIKER  who  evades  the  SAM.  The  STRIKER 
survives. 

Lesson:  The  simulation  is  unrealistic,  and  worse,  it  erroneously  predicts  the  STRIKER  gets  away. 

This  is  not  acceptable  for  realistic  simulation  planning  -people  can  get  killed. 

Scenario  2  -  JSAF  w /  Comms  but  no  Relay:  The  SOF  uses  JTIDS  to  send  a  threat  warning  to  the 
STRIKER  but  the  mountain  range  blocks  direct  radio  contact.  The  STRIKER  gets  hit. 

Lesson.  There  is  a  need  to  account  for  distance,  terrain  and  network  design  in  realistic  mission  planning! 

Scenario  3  -  JSAF  w/  Comms  and  Relay:  Based  on  the  results  of  the  prior  run,  we  turn  on  a  JTIDS  relay 
on  a  UAV.  The  results,  the  STRIKER  gets  the  relayed  threat  warning  and  evades!  The  STRIKER  gets 
away. 

Lesson :  Communications  modeling  and  advanced  planning  in  support  of  operations  is  critically  important! 

Because  the  simulation  detected  communications  failure,  required  adjustments  can  be  made  to  the 
deployment  and  network  design  to  ensure  success  of  the  mission. 

The  flight  path  of  the  F-15  STRIKER  aircraft  is  shown  in  Figure  4-12.  Crosses  along  the  path  indicate  waypoints.  The 
SOF  is  in  the  upper  right  near  the  TCT  (square)  and  pop-up  threats  (crosses).  The  UAV  in  the  upper  left  follows  a  flight 
path  that  keeps  it  near  the  area  of  operation.  In  Figure  4-12,  the  F-15  has  entered  the  valley  on  its  way  to  the  target.  The 
heavy  dotted  line  indicates  that  direct  communications  with  the  SOF  are  broken  due  to  the  mountain  range.  The  other 
heavy  lines  indicate  good  network  connection  between  the  UAV  and  the  F-15  and  to  the  SOF.  Additional  details  on  the 
design  of  the  “Wow”  scenario  and  its  associated  JTIDS  networks  are  discussed  in  the  next  section. 


3  The  term  STRIKER  is  used  to  refer  to  tactical  aircraft  with  the  mission  assignment  of  striking  a  target. 
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Figure  4-11.  SOF,  STRIKER,  UAV  Relay,  Time  Sensitive  Target  and  Threats  in  the  66 Wow”  Scenario 
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5.0  LESSONS  LEARNED 


This  section  summarizes  the  lessons  learned  during  this  effort.  These  are  organized  into  the  following  topics: 

•  Subject  Matter  Experts  are  critical  to  the  success  of  the  program  from  communication  needs  to 
communication  simulations  development  to  execution  of  the  scenario. 

•  Defining  and  Developing  realistic  operational  tactical  communication  scenarios  should  not  be 
underestimated.  This  is  a  difficult  area;  however  it  is  a  vital  area  rich  in  system  payoff. 

•  War  Gaming  Software  application  integration  is  complicated  requiring  expert,  experienced,  and 
knowledgeable  system  developers  to  accomplish  the  planned  goals  and  objectives. 

•  Repeatability:  It  is  important  that  the  Subject  Matter  Experts  review  and  refine  the  demonstration 
scenario(s)  for  realism  and  future/advanced  communication  needs. 

•  JSAF  Software  Complexity. 

5.1  Criticality  of  Subject  Matter  Experts 

Subject  Matter  Experts  were  critical  to  the  success  of  the  GIESim  program  from  communication  needs  to 
communication  simulations  development  to  execution  of  the  scenario(s).  Retired,  experienced  Air  Force  mission 
experts  within  the  intelligence  operations  area,  provided  real-world  scenarios  with  realistic  communications 
equipment  staging  along  the  legs  of  the  operational  steps  of  the  mission  simulations. 

5.2  Communication  Scenarios 

Scenario  development  has  been  and  continues  to  be  a  very  demanding  process.  Also,  the  need  for  mission 
operational  subject  area  experts  is  critical  and  increasing.  Knowing  that  these  experts  are  fewer  in  number,  a 
requirement  exists  for  the  capture  and  development  of  scenario  databases  to  support  the  next  generation  of  M&S. 
Future  systems  depend  on  the  M&S  technology  step  to  push  the  envelope  of  technicality. 

5.3  JSAF  Software  Complexity 

The  JSAF  software  is  very  large  and  complex.  It  consists  of  more  than  1000  individual  software  object  libraries. 
There  is  a  complex  web  of  dependencies  that  connects  these  libraries  to  one  another.  The  JSAF  software  is  written 
in  ANSI  C,  and  has  a  multifaceted  object-based  architecture  that  simulates  inheritance  and  aggregation  relationships 
among  libraries.  Extensive  configuration  script  and  reader  (i.e.,  data)  files  further  add  to  this  complexity.  This 
complexity  makes  the  JSAF  software  very  difficult  to  modify.  Adding  a  new  type  of  object  attributes  -  for  example, 
a  ground  vehicle,  for  example  (i.e.,  a  taxi)  that  could  require  that  additions  be  made  to  approximately  a  dozen 
different  source  code,  configuration  script,  and  reader  files. 

5.4  GIESim-JSAF  Software  Application  Integration 

Without  the  joint  GIESim  and  JSAF  Team  knowledge  within  their  respective  application  areas,  the  software 
integration  and  modification  process  would  have  been  much  more  difficult  and  costly.  The  complexity  of  both 
software  packages  (GIESim  and  JSAF)  would  have  made  this  integration  time  consuming  and  a  low  payoff  venture. 
AFRL,  PSI,  SAIC,  NG,  and  SRC  are  to  be  commended  for  their  respective  management  and  technical  expertise  and 
the  achievement  of  the  GIESim-JSAF  merger. 
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6.0  PROPOSED  FUTURE  WORK 


The  following  paragraphs  provide  proposed  new  work  areas  for  consideration.  The  first  GIESim/JSB-RD  Additional 
Effort  provides  technology  that  would  enhance  the  current  GIESim/JSAF  merger  software,  whereas  the  second  and 
third  provides  areas  that  could  be  potentially  high  payoffs.  However,  these  two  areas  will  need  more  investigation  to 
identify  what  could  be  performed  by  future  GIESim  efforts. 

6.1  GIESim/JSB-RD  Additional  Effort 

The  GIESim/JSB-RD  merger  of  tactical  JTIDS  communications  with  JSAF  was,  and  is,  a  success.  Additional  effort 
is  required  to  take  this  accomplishment  from  a  successful  proof-of-concept  demonstration  to  a  fully  scaled-up, 
robust  capability  for  use  in  large  war  gaming  activities.  Larger  scenarios  must  be  explored  with  more  complex 
tactical  messaging.  Cross-simulation  scenario  design  needs  to  be  made  easier  and  mission  goals  must  feed  network 
requirements.  Furthermore,  scalability  must  be  explored  to  determine  the  computational  architecture  that  may  be 
required  for  high  message  traffic  in  large  scenarios.  While  this  may  be  complex,  the  merger  team  has  laid  the 
groundwork  and  established  a  foundation  to  make  this  happen  rapidly  at  low  cost. 

The  merger  team  has  taken  a  large  step  that  provides  a  forum  for  mission,  communications,  and  operations  planners 
to  work  together  in  a  distributed  simulation  environment.  Network  Centric  Operations  requires  C3,  and  the  merger 
has  added  Communications  to  Command  and  Control  to  realize  the  needed  C3.  The  merger  has  also  opened  the  door 
to  the  integration  of  other  tactical  communications  to  JSAF.  Training  and  gaming  can  now  begin  to  take  on 
communications  challenges  in  a  realistic  way.  The  combined  merger  team  has  the  experience  to  make  this  happen. 

6.2  Airborne  Network 

Additionally,  the  Airborne  Network  system  must  be  explored  as  a  development  and  integration  point.  GIESim 
simulated  today’s  aircraft  information  exchange  via  data  links,  which  communicate  specific  information  to  specific 
radios  in  specified  message  formats.  In  contrast,  network  connectivity  provides  global  access  to  information  and  the 
ability  to  pull  or  push  information  to  all  others  connected  to  the  network.  If  two  aircraft  are  connected  to  the 
network,  they  will  be  able  to  exchange  information,  even  if  they  do  not  have  a  direct  connection.  The  challenge  and 
requirements  for  the  airborne  network  is  to  make  what  works  in  a  ground-(based)  environment  work  in  an  airborne- 
dynamic  environment.  Wires  and  fiber  optic  cables  provide  the  “backbone”  for  ground-based  networks;  space-based 
optical  lasers  and  aircraft  carrying  advanced  communications  systems  will  form  the  backbone  of  the  airborne 
network.  Large  aircraft  and  unmanned  air  vehicles,  equipped  with  greater  communications  capability,  bandwidth, 
and  connections  to  space  and  ground,  could  provide  the  backbone-in-the-sky.  This  type  of  Modeling  and  Simulation 
communication  environment  should  be  the  next  consideration  within  GIESim/JSAF  advancement  and  future 
development. 

6.3  Optical  &  RF  Combined  Link  Experiment  (ORCLE) 

The  Defense  Advanced  Research  Projects  Agency's  (DARPA)  has  sponsored  a  BAA  to  investigate,  prototype,  and 
demonstrate  an  Air-to- Air- to- Surface  hybrid  [combined  and  simultaneous  Free  Space  Optical  (FSO)  and  Radio 
Frequency  (RF)]  link  and  networking  concept  that  has  a  compact  form  factor,  high  availability,  and  high  average 
data  rate  under  all  weather  conditions.  The  principal  focus  of  the  BAA  ORCLE  is  the  Range  and  Flight 
Demonstration  Systems  Integration  and  the  Technology  Maturation  that  includes: 

•  Optical  Channel  Obscuration  Mitigation  (i.e.,  transmission  through  clouds) 

•  Common/Combined  FSO/RF  aperture 

•  Compact  Optical  Beam  Steering 

•  Hybrid  (FSO  &  RF)  Router  Technology 
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8.0  ACRONYMS 


AF 

Air  Force 

AFRL 

Air  Force  Research  Laboratory 

AGI 

Analytical  Graphics  Inc. 

BAA 

Broad  Area  Announcement 

CAST 

Communications  Analysis  and  Simulation  Toolkit 

CDMA 

Collision  Detection  Multiple  Access 

CONOP 

Concept  of  Operations 

CONUS 

Continental  US 

DARPA 

Defense  Advanced  Research  Projects  Agency 

DMSO 

Defense  Modeling  and  Simulation  Office 

DoD 

Department  of  Defense 

FDMA 

Frequency  Detection  Multiple  Access 

FOM 

Federation  Object  Model 

FSO 

Free  Space  Optical 

FTI 

Frontier  Technology,  Inc. 

GIE 

Global  Information  Enterprise 

GIESIM 

Global  Information  Enterprise  Modeling  &  Simulation 

GIESIM-JSAF 

Global  Information  Enterprise- Joint  Semi- Automated  Forces 

GSS 

General  Simulation  System 

HLA 

High  Level  Architecture 

IFGA 

Distributed  Information  Systems  Branch 

JBI 

Joint  Battlespace  Infosphere 

JBISIM 

Joint  Battlespace  Infosphere  Simulation 

JSAF 

Joint  Semi- Automated  Forces 

JTIDS 

Joint  Tactical  Information  Distribution  System 

M&S 

Modeling  &  Simulation 

MOE 

Measures  of  Effectiveness 

MOM 

Measures  of  Merit 

MOP 

Measures  of  Performance 

NAM 

Network  Animator 

NMS 

Network  Management  System 

ODK 

OPNET  Development  Kit 

ORCLE 

Optical  &  RF  Combined  Link  Experiment 

OT&E 

Operational  Test  and  Evaluation 

PSI 

Prediction  Systems,  Inc. 

RF 

Radio  Frequency 

RTI 

Run  Time  Infrastructure 

RTI-S 

Run  Time  Infrastructure- s  (partial  implementation) 

SAIC 

Science  Applications  International  Corporation 

SAM 

surface-to-air  missile 

SATCOM 

satellite  communications 

SOF 

Special  Operations  Force 

SRC 

Syracuse  Research  Corporation 

STK 

Satellite  Toolkit 

TDMA 

Time  Detection  Multiple  Access 

TEM 

Technical  Exchange  Meeting 

TST 

Time  Sensitive  Target 

UAV 

Unmanned  Aerial  Vehicle 
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